Connectivity determining spanning-tree algorithms may be run centrally via Network Management Systems (NMS) by analysts. To do so the analyst and the associated NMS must posses a large amount of information regarding data transport infrastructure in a realm of management of the NMS. Central spanning-tree determination benefits from an availability of the resulting spanning-tree for the analysts perusal in providing support for manual VLAN provisioning. Such solutions however tend to be reactive as data transport equipment failure instances require the analyst's attention at least in re-provisioning VLANs to re-establish VLAN connectivity over reconfigured spanning-trees.
In order to reduce network management and service provisioning overheads, the spanning-tree protocol may be implemented in a decentralized fashion with each data network node and data switching nodes running spanning-tree determination algorithms. A collective exchange of information therebetween provides the necessary information to determine and establish spanning-tree connectivity. While such a solution reduces the need for analyst intervention in re-establishing data transport connectivity subsequent to data transport infrastructure failures, the active in-use spanning-tree exists typically only as operational parameter configurations within individual data transport equipment and is unavailable to the analyst and the NMS for re-provisioning VLAN connectivity.
While co-pending commonly assigned Unites States Patent Application entitled “Virtual Local Area Network Auto-Discovery Methods” filed on even date, bearing attorney reference number 13597-US; describes methods of deriving VLAN configuration information from participating data network nodes, the described methods do not delve into VLAN provisioning. A considerable operational overhead is still incurred in manual VLAN provisioning.
Referring to FIG. 1, prior art VLAN provisioning is performed manually by configuring individual data transport and switching equipment to provision trunk ports (TP) 102 and access ports (AP) 104 of manually selected data switching nodes 106 in a service provider (carrier) network 100. Such a prior art manual VLAN provisioning solution is provided by CISCO Systems' VLAN Director software version 2.1.
The access ports 104 are connected via access links 130 to the customer LANs 110 and the trunk ports 102 are connected to the data transport trunks 108 between the data switching nodes 106.
The use of the spanning-tree protocol avoids the creation of loops in the data transport network 100 by putting certain data transport trunks 108 in a stand-by state thereby preventing the replication of data packets 120/122 thereto as would otherwise result. Stand-by data transport trunks 108 are shown by dashing in the FIG. 1. In-use data transport trunks 108 are shown solid. A similar depiction is used with respect to the corresponding ports 102. Prior art VLAN provisioning methods typically call only for the trunk ports 102 and routers 106 associated with in-use data transport trunks 108 to be included in VLAN provisioning.
In accordance with the example shown in FIG. 1, the configuration of VLAN2 includes three customer LAN segments 110 at respective sites 1, 3, and 5; the LAN segments 110 are connected to respective routers 106-R1, 106-R3, and 106-R2 of a service provider's data transport network 100. Packets 120 of VLAN2 are routed over the shared service provider's carrier network 100 in accordance with the spanning-tree protocol, which has designated: router 106-R5 as a spanning-tree root node, data transport trunks 108-dashed on stand-by to prevent the formation of logical loops in the data transport network 100, and data transport trunks 108-solid in-use. For example, VLAN2 is provisioned only on ports 102-P1 and 102-P2 on each of routers 106-R1, 106-R2, and 106-R3 and on ports 102-P1, 102-P2, and 102-P3 on router 106-R5.
Data packets 120/122 are routed through the carrier data transport network 100 over the loop-free spanning-tree of data transport trunks 108-solid using Open Systems Interconnect (OSI) Layer-2, typically Media Access Control ADDResses (MAC ADDRs) conveyed in data packet 120 headers when the trunk ports 102 are provisioned (associated) with only one VLAN. In the case where a trunk port 102 is provisioned to support more than one VLAN, a VLAN identifier is added in the packet headers (122) in accordance with the IEEE 802.1Q protocol incorporated herein by reference. The VLAN identifier is used to route data packets 122 through the network 100 and the VLAN identifier is removed from packet headers when no longer needed. Ports 102-P2 of routers 106-R2 and 106-R5 are provisioned for both VLAN2 and VLAN3. VLAN data packets 122 thereby necessitate the use of the VLAN identifier to differentiate data traffic.
As routing examples, a packet 120 is shown to be routed from data network node 112-A to data network node 112-B using only the MAC address of node 112-B; another packet 122 is shown to be routed from node 112-C to node 112-D using the VLAN identifier for VLAN3 between routers 106-R2 and 106-R5, and using the MAC address for node 112-D over the rest of the data transport path.
In the event of a service-affecting fault, the spanning-tree protocol will recalculate the spanning-tree and re-assign data transport trunks 108 in-use.
The problem with the prior art solutions resented above lies in determining which data transport trunks 108 are chosen for use by the spanning-tree protocol. Such determination can be difficult and time-consuming, thereby making provisioning of VLANs likewise difficult and time-consuming. This is especially the case for large and complex data transport networks 100. The redefinition of the spanning-tree requires corresponding manual re-provisioning of the VLANs. Such manual provisioning is error prone.
Another development in the field which addresses VLAN provisioning methods is exemplified by CISCO's VLAN Trunk Protocol (VTP). The VLAN trunk protocol is a CISCO Systems proprietary solution to propagating manually configured VLAN information between adjacent VTP aware network elements. The propagation of VTP information is implemented as differentiated data traffic over VLAN 1 which means that VLAN support must be apriori activated for each VTP aware network element. To date only selected CISCO Catalyst products support the VTP protocol. The suitability for using the VTP protocol is dependent on: the definition of VTP domains of which other vendor equipment would be unaware, the establishment of VTP server/client relationships between VTP aware (CISCO only) network elements, memory for storage of VTP related information at each participating VTP aware network element, the ability to parse VTP specific frames, the ability to respond to a particular reserved broadcast address in exchanging VTP related information, etc. Although some benefit may be derived from the use of the VTP protocol over a CISCO only network equipment infrastructure, numerous shortcomings of the present definition of the VTP protocol call for the reduction of the extent of provisioned VLANs, which runs counter to the need to extent VLANs beyond the restrictions imposed by the physical network infrastructure. Various workarounds call for quick manual re-provisioning of VLAN support as the only reactive solution.
The demand for VLAN services has been and continues to be so great that the 12 bits allocated in accordance with the IEEE 802.1Q VLAN protocol is not enough. The IEEE 802.1Q VLAN protocol makes it possible for the provisioning of over 4000 VLANs with some VLAN identifiers being reserved for VLAN protocol functions and future feature development. The proliferation of VLAN services and the multitude of service providers has created situations in which VLAN service customers own part of the VLAN infrastructure, in most cases owning the necessary VLAN provisioning customer premise equipment. Although the co-pending commonly assigned United States Patent Application bearing attorney reference 13596-US entitled “Improved Virtual Local Area Network Provisioning in Bridged Networks”, incorporated herein by reference, provides centralized methods of VLAN provisioning ensuring uniqueness of IEEE 802.1Q VLAN identifiers, VLAN customers in charge of their respective infrastructure perceive the VLAN identifier restrictions imposed by VLAN service providers restrictive, bothersome, and not portable. The portability of IEEE 802.1Q VLAN identifiers is important as VLAN customers change service providers as needs for data transport services change for reasons such as, but not limited to, needing additional capacity deliverable only over different physical layer technologies supported only by select service providers. There is a need to address issues of IEEE 802.1Q VLAN identifier portability to reduce possible customer-side data transport disruptions.
Inadvertent sharing of VLAN identifiers between customers in a provisioning scenario in which VLAN uniqueness is not centrally guaranteed becomes possible. Inadvertent sharing of VLAN identifier between customers leads to possible packet exchange between customers' private networks compromising data transfer security possibly leading to unwanted disclosure of closely held information. There is a need guard against this security risk in providing VLAN identifier portability.
Developments in the field addressing the issue of VLAN identifier portability while ensuring data traffic differentiation include a proposed extension to the IEEE 802.1Q VLAN protocol by Riverstone Networks. The IEEE 802.1Q VLAN protocol extension proposes the use of an additional extension 802.1Q packet header to provide additional extended identifying bits. The use of the additional packet header provides for a hierarchical grouping of VLANs referred to VLAN stacking. FIG. 2 is a schematic diagram showing exemplary packet structures as specified in the IEEE 802.1Q VLAN protocol and the Riverstone solution, respectively; the Riverstone solution enables reuse of standard IEEE 802.1Q VLAN identifiers as long as the combined VLAN identification is unique.
The use of stackable VLAN technology complicates VLAN provisioning and VLAN management tasks due to the larger number of possible VLANs, while network management tools are limited to network element management specific tools such as Softelia™, provided by Riverstone Networks, akin to CISCO-type network element management solutions and therefore suffering from the same shortcomings mentioned above.
There therefore is a need to reduce operational overheads in provisioning VLAN support in data transport networks and lessen the reliance of provisioning on trained personnel.